Pedagogy guide

What to teach, in what order, and why that order

The common mistake is starting with the engine, because the engine is the thing that looks like the subject. Students who start in an engine learn to assemble, and then spend two years being unable to say why anything they assembled is any good. Design first, tools second, and the tools land better because there is now something to build.

1. Play something badly on purpose Before any theory, make them play a deliberately broken game for two minutes. A dice game with no decisions works. They need the feeling of a dead loop in their hands before the words mean anything.
   Why first: every term after this you will say the loop is the game. That sentence is abstract until they have felt a loop fail.
2. Core loops The verb, the consequence, the reason to repeat. Strip existing games down to three lines. This is the backbone and everything later hangs off it.
   Why second: it is the only concept that applies to every single thing they will make, including the ones that are not video games.
3. Paper prototyping Before any software. Ten minute builds that answer one question. They will resist this and the resistance is worth absorbing once.
   Why here: it gives them a way to test an idea that does not depend on skills they do not have yet. It also removes the excuse that they cannot start until they can code.
4. Playtesting How to run one and how to read one. Silence, observation, what they expected rather than what they want.
   Why before the engine: if they learn to test on paper, they will test their builds. If they learn to build first, testing becomes a thing they do at the end, which is to say never.
5. Scope control Hours, not weeks. The cut list. The protected feature. Do this before the big project starts, not in the middle of it.
   Why here: every student is about to propose something four times too large. Teaching this after they have fallen in love with the oversized idea is much harder.
6. First build in an engine Empty project to something that moves. Six words: scene, object, component, script, run, stop. Everything else gets looked up when needed.
   Why now: they finally have a design worth implementing, and a reason to care about the tool rather than the tool being the point.
7. Level design and game feel, together Space teaches the player, timing makes the action live. Both are cheap to change early and brutal to retrofit.
   Why paired: students treat feel as polish and polish as optional. Teaching it next to level design frames both as structure.
8. Systems and balance Dominant strategies, feedback loops, the sentence that justifies each option. Needs a working thing to be applied to, which is why it is late.
   Why late: balance is meaningless without something to balance. Taught early it becomes a maths lesson they will not transfer.
9. Finishing Definition of done, the stranger test, bug triage. Two to three weeks before the deadline, not in the last week.
   Why not last: if you teach finishing in the final week, you have taught it as a panic. Taught with three weeks left, it is a plan.

What students actually believe, and what to do about it

These are not gaps in knowledge, they are working theories that have served them well as players and serve them badly as makers. Arguing with them does not work. Putting them in a situation where the theory visibly fails does.

Assessing work that is played rather than read

Most rubrics used for game work are essay rubrics with the words changed. They reward documentation, because documentation is what the rubric knows how to read, and students learn within about two weeks to write well about a game they did not finish. The fix is not to stop reading the documentation. It is to mark the thing that happened, not only the thing that was handed in.

The two minute viva, which is the single highest value thing on this page

Two minutes per student, at their desk, while the rest of the class works. One question, not prepared, about a decision they made. "Why does the player lose the block when they push it?" Or "what did you try before this?" You are not interrogating anybody and you are not looking for a confession. You are finding out whether the thinking is theirs, and you will know inside thirty seconds without ever having to accuse anyone of anything.

At thirty students that is an hour, which is less time than marking thirty documents and produces better evidence. It also works as an assessment in its own right, it is close to impossible to outsource, and students who have done it once prepare differently for everything afterwards.

Rubric builder writes rubrics on these lines, with criteria for iteration and scope rather than for presentation. Assignment triage will tell you how exposed a given task is before you set it.

Running a playtest as a lesson

A playtest lesson fails in predictable ways: designers rescue their testers, testers are polite to their friends, and the whole thing collapses into opinions in the last ten minutes. All three are solvable with structure set up before anyone plays anything.

The shape that holds, in a single period

The three rules worth writing on the board

When there is nothing built yet

Run it anyway on paper. A level sketch can be tested by having someone trace the route with a finger and say out loud what they think each room is teaching them. A rules sheet can be tested by handing it over and watching how far they get before they ask a question. Both produce real findings and neither requires a single line of code, which also means the lesson survives a room with no working machines.

Classroom reality

The student who wants to make an MMO

Do not say no and do not say it is too big, because both read as a judgement about them. Ask them to build the smallest piece of it that works on its own: one room, two players, one interaction. Frame it as the first slice of the real thing rather than as a consolation prize. Most of them discover for themselves, somewhere in week two, how much work one room is, and that discovery is worth more than any warning you could have given.

The student who only wants to make art

Let them, and then mark the design. Give them a brief where the art has to carry a mechanic: a level where colour tells the player what is dangerous, or a character whose silhouette tells you what they can do. The art stays and the design thinking arrives through it. Fighting this head on usually loses you the student.

The student who finishes in twenty minutes

They almost never finished, they stopped. Have a constraint ready rather than more work: do it again with one fewer tool, or make the same thing feel heavy instead of light, or make the hardest version first. Adding breadth rewards speed. Adding constraint rewards thinking, and it costs you nothing to prepare because the constraint is the same one every time.

The room with no working machines

Roughly a third of this subject is better on paper anyway. Loops, systems, balance, level structure, playtesting and scope all work with index cards. If the machines are unreliable, plan the term so the engine work sits in a block you can move, rather than spreading it through every week where one failure breaks the sequence.

Mixed ability, which is every class

Game work handles this better than most subjects because the same brief absorbs very different levels of ambition. One brief, three scaffolds: supply the mechanic for the ones who need a start, supply the constraint for the ones who need a ceiling, and leave the middle to choose. The thing to avoid is three different tasks, because then you cannot run a shared share stage and you lose the part of the lesson where they learn from each other.

You have never made a game yourself

That is fine and you should say so once, out loud, early. Then make something small in front of them and let it go badly. You will teach more about iteration in that twenty minutes than in a term of explaining it, and the class relationship it buys you is worth more than the expertise you were worried about not having. The subject is unusually forgiving about this because the students can see whether the thing works, which means you are not the only authority in the room.

Where AI fits in this subject, honestly

Game development is one of the places where generative tools are genuinely useful to a beginner and genuinely corrosive to learning, in different parts of the same project. Treating it as one question gets you a policy nobody follows.

The policy that survives contact with a class

Per task, not per course. A blanket ban is unenforceable and everybody in the room knows it, which teaches students that your rules are decorative and does more damage than the tool does. Name the allowed use for each task in one line, and make them show it: paste the prompts, note what the model got wrong, say what you changed. That turns the tool into something you can assess rather than something you are pretending is not there.

The structural answer in this subject is easier than in most, because the work is already anchored to things a model cannot reach. A playtest that happened in your room on Tuesday. A design decision defended out loud in two minutes. A level built around a real place the student has walked through. Game design is unusually resistant to outsourcing if you assess the process rather than the artefact, and the process is the part you wanted to teach anyway.

Assignment triage will score any specific task and write the policy line for it.